home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-21 / aview64f.zip / WHATSUP.DOC < prev   
Text File  |  1992-09-08  |  9KB  |  196 lines
  1. 09/08/92
  2.  
  3. Errors will occur using PKZIP V1.01.  Upgrade to v1.10
  4.  
  5. 07/06/92
  6.  
  7. The v3.50 of WildCat has corrected the problem with line 30 in the DOOR.SYS
  8. file.
  9.  
  10. 05/17/92
  11.  
  12. Added a few new command line parameters.  Please review the AVIEWCOM.HST
  13. file for details on changes, and AVIEWCOM.DOC for further information on
  14. the new parameters.  Also, PKUNZIP v1.1 recognized -x and -e as parameters,
  15. but the new PKUNZIP v1.93 only recognized -e.  Further, PKUNZIP v1.01 only
  16. recognized -x.  I have chosen to use the -e parameter.  If you do not have
  17. PKUNZIP v1.1 or newer, please upgrade to a newer version.
  18.  
  19. 04/15/92
  20.  
  21. AViewCom will detect if DesqView is resident and will enable the patch
  22. to prevent crashes.  Part of this is a pause for keypress before shelling
  23. to an external program.  If your system does NOT crash while reading a
  24. text file with earlier versions of AViewCom, then include the -q parameter
  25. on the command line to disable this pause.
  26.  
  27. 04/14/92
  28.  
  29. Thanks to some supportive help from Robert Cole from Mustang Software,
  30. I have found a patch that seems to avoid the problem of AViewCom crashing
  31. while running under some DesqView systems.  The problem resides either in
  32. the gettext() or spawnlp() functions of TurboC as I am using them.  I will
  33. be talking with Borland and QuarterDeck to come up with a true fix for the
  34. problem.  For the moment, I have implemented a patch to hopefully avoid the
  35. problem.  If you run a DesqView system, please let me know if you have any
  36. trouble with "Reading a text file" or "Downloading a file" while using this
  37. version.  There are many who have helped me over the years narrow in on this
  38. problem.  I can't mention all of them, but I'd like to offer a special thanks
  39. to Dave Codey, Minos Tsaussis, Pat Nefos, Scott Burch, and Rick Hemming.
  40.  
  41. 04/05/92
  42.  
  43. PAK.EXE v2.51 is a memory hog and will take all remaining memory when
  44. called.  With 400 kbytes free, PAK.EXE would not extract the file I
  45. requested and gave no reason.  I guess the 400 kbytes wasn't enough.
  46.  
  47. 03/30/92
  48.  
  49. In an attempt to loacate and fix the DV bug in AViewCom, I have
  50. completely re-written and re-structured the code.  I had hoped that in
  51. the process, to fix the bug which has caused DV users so many headaches.
  52. However, I was unsuccessful.  I am now using the SMALL memory model
  53. instead of the LARGE memory model to compile the program.  It will run
  54. faster now.  It now uses 103 kbytes of memory.  Also, the maximum
  55. filename capacity of files within an archive has been increased from a
  56. limit of 255 to no limit.  The filenames are stored in a temporary file
  57. called AVIEWLST.nnn where nnn is a number from 0 to 999 allowing 1000
  58. nodes to use seperate temporary files simultaneously.  I have also
  59. addes several useful new features to the program.  In addition, the
  60. documention has been completely re-written.
  61.  
  62. 03/11/92
  63.  
  64. I must apologize to several people for being so unavailable for the past
  65. few months.  I've been involved in another project and worked 80 hours a
  66. week for the last 15 weeks of 1991.  I spent the first couple months of
  67. this year recovering.  I'm back now and am working on v6.2.  For DesqView
  68. users, there was a mention of a STEALTH.TEC text file posted on Quarter
  69. Deck SW Support BBS which has a fix for the memory conflict problem with
  70. AViewCom.  I haven't read this, can someone let me know if this fix works?
  71. Some DesqView users are not aware that DVANSI.COM should be loaded prior
  72. to running WildCat to allow AViewCom to properly display ANSI characters.
  73. Be sure to include DVANSI in your CAT.BAT batch file.
  74.  
  75. 10/12/91
  76.  
  77. It has been brought to my attention that at times, AViewCom will report
  78. that a user's download kbyte limit has been exceeded when they attempt
  79. to download a file.  This happens sometimes because WildCat improperly
  80. writes line 30 in DOOR.SYS.  It should write the DAILY DOWNLOAD KBYTES
  81. TOTAL, but instead, it is writing the same value as line 48 which is
  82. TOTAL DOWNLOAD KBYTES (from day one!).  Since AViewCom is used with 
  83. other types of BBS's and reads DOOR.SYS which is created properly by
  84. them, I will not change AViewCom to adjust for this WildCat bug.  Instead,
  85. WildCat SysOps should request a bug fix from Mustang.
  86.  
  87. 10/10/91
  88.  
  89. For those running multi-nodes under DesqView, it has been discovered
  90. that using LOADHIGH causes AVIEWCOM to lockup when attempting to
  91. extract a file from an archive.  Removing the LOADHIGH operations
  92. alieviated this problem in one DesqView installaion.
  93.  
  94. 09/19/91
  95.  
  96. I have implemented the update user function by reading USERINFO.DAT
  97. and modifying the last two lines to reflect the number of downloads
  98. and download kbytes.  However, this is supposed to be a read/write
  99. file but WildCat does not yet read this file back in and update the
  100. allusers.dat file.  Since there is too much risk in corrupting the
  101. database by having AViewCom update the database, the update user
  102. function will not be active until WildCat reads back in the
  103. USERINFO.DAT file.
  104.  
  105. 09/05/91
  106.  
  107. AViewCom v6.1c is the first release which will read the DOOR.SYS
  108. file.  I was amazed that the number of inquiries about this version
  109. far exceeded the number of registrations I have received to date.
  110. The shareware version has some functions disabled including reading
  111. the DOOR.SYS file.  The shareware version will still run correctly
  112. under WildCat v3.n even without reading DOOR.SYS.
  113.  
  114. 08/25/91
  115.  
  116. Work has started on supporting WildCat v3.0.  I have added the
  117. function to read in the DOOR.SYS file, but I still need more
  118. information than is provided in that file:  system upload/download
  119. ratio limit, and maximum download kbytes allowed.
  120.  
  121. 06/08/91
  122.  
  123. Work will start soon on supporting the WildCat v3.0 databases.
  124. I've spent multi-hours on the phone with two generous and helpful
  125. sysops trying to debug the desqview problem with moderate progress.
  126. The cause is still unknown, but I have found that pkunzip is NOT
  127. the problem.  AViewCom locks up before getting to that point.
  128.  
  129. 05/25/91
  130.  
  131. I have found several systems that have successuflly run WildCat
  132. under DesqView with no problems, but other systems which will lock
  133. up every time when AViewCom shells out to pkunzip.  My system with
  134. a test copy of these programs works well.  The investigation as to
  135. the cause of this problem with some systems locking up is ongoing.
  136.  
  137. 04/21/91
  138.  
  139. The number one bug report currently is that AViewCom will lock-up
  140. the system when shelling out to pkunzip and running under DesqView,
  141. and WildCat.  I understand that with older versions of DesqView
  142. and WildCat this did not happen.  I am planning on investigating
  143. this problem further.
  144.  
  145. 09/28/90
  146.  
  147. AViewCom now performs dynamic disk swapping.  There are five
  148. modules within the program which are swapped out as they are used.
  149. This will reduce the memory usage some, but the major memory usage
  150. still remains with the archiver which AViewCom shells out to.  As a
  151. note, PKUNZIP requires 260K of memory!  Also, VIEW.OVL is no longer
  152. required.
  153.  
  154. 08/21/90
  155.  
  156. I have tested AViewCom v4.4e with DesqView v2.26 with direct screen
  157. writes enabled, and as far as I can tell (I'm not a DesqView
  158. user!), it works okay - AViewCom doesn't overwrite other screens
  159. when you're in other windows.  I have also added the PIF file which
  160. you should review and change as needed.
  161.  
  162. 07/04/90
  163.  
  164. Mustang has release v2.15.  I have had reports that the AVUSER
  165. functions is not working properly with the new version.  I will
  166. have this fixed with the next release which will also work under
  167. DeskView and multi-node systems.
  168.  
  169. 03/04/90
  170.  
  171. Mustang will soon be releasing a v2.15 which will create the CALLINFO.BBS
  172. file when spawning out to the arcviewer.  I believe this file is different
  173. from the one that aviewcom made but I don't know what yet.  AViewCom v4.5
  174. will be able to use it, and will properly function in the avuser mode.
  175. Sysops are cautioned on the use of the avuser function until this function
  176. is verified with the new version.
  177.  
  178. 01/01/90
  179.  
  180. I have incorported the functions of CALLINF2, AVSETUP, and AVUSER into
  181. AVIEWCOM.  These are accessed by command line switches beginning with
  182. a slash.  To invoke AVSETUP, type AVIEWCOM /S.  To invoke AVUSER, type
  183. AVIEWCOM /U.  To invoke CALLINF2, type AVIEWCOM /C.
  184.  
  185. 09/23/89
  186.  
  187. AViewCom will now update the user database to reflect: 1) total
  188. downloads, 2) total download kbytes, 3) daily downloads, and 4)
  189. daily download kbytes.  It does not update number of accesses for
  190. the files downloaded (USERFILE.DAT is the only file altered).
  191. The updating feature does not work with multi-node systems.
  192. AViewCom v3 will be updated for the ShareWare market and will not
  193. support WildCat v2.0.  AViewCom v4 will be updated for Registered
  194. users only.  Mustang is working on a WildCat version 3 which will
  195. eliminate the need for AVIEWCOM /C and AVIEWCOM /U.
  196.